Technological advances and legislative requirements in encryption, digital certification, and electronic signatures have presented both opportunities and challenges for business and government entities wishing to conduct transactions securely over communications networks such as the Internet. Several standards and protocols have been developed and are being developed for use in such applications. Public key infrastructure (PKI) is one security infrastructure designed for use with the Internet that provides a framework for managing digital certificates and their associated public/private key pairs. Public key cryptography is normally associated with asymmetric cryptography. However, PKI can utilize elements of both asymmetric and symmetric cryptography, whose nature is known to those skilled in the art. The terms public key cryptography and asymmetric cryptography are used interchangeably in the present application.
PKI provides several encryption and security services, which are generally grouped under the categories of confidentiality, authentication, integrity and non-repudiation.
“Confidentiality” is the protection of data against unauthorized access or disclosure, and prevents those to whom a transmission was not intended from accessing the information within the transmission.
“Authentication” is the verification of a party's identity or the verification of the source of information. Authentication can be achieved by use of passwords, keys, or other means for recognition.
“Integrity” is the protection of data against unauthorized modification or substitution to information. This service is usually provided by cryptography mechanisms called message authentication codes (MAC) or digital signatures.
“Non-repudiation” is the combined services of authentication and integrity that is provable to a third party. The goal of non-repudiation is to prevent an originator of a message from denying having originated the message.
These services are explained in more detail, for example, in the book PKI by Tom Austin, John Wiley & Sons, Inc., 2001, which is hereby incorporated by reference.
Thus, unlike the situation used in symmetric encryption techniques, wherein identical keys are used to encrypt and decrypt, public key encryption or asymmetric encryption techniques use a public key to encrypt the information and a different corresponding private key to decrypt the information. Public key encryption techniques provide certain features not available in symmetric encryption, including the ability to ensure non-repudiation, as discussed above.
Public key encryption systems require key management capabilities. Key management, sometimes referred to as key “life cycle” management, generally comprises the following phases: “key generation,” referring to the process of initially creating the keys; “key distribution,” referring to the movement of keys from one location to another; “key storage,” referring to storing cryptographic keys following key distribution, in preparation for actually using the keys; “key usage,” referring to the actual use of a key in a cryptographic application or transaction; “key recovery,” referring to backing up keys, for reasons of reconstituting a cryptographic key due to hardware or software failure or loss of authorized access control; “key termination,” referring to the point when a key has reached the end of its life cycle, either due to a predetermined validity period (such as expiration) or a suspected or known compromise; and “key archival,” which refers to retention of a copy of a key which has been terminated, placing the key in secure storage for the purpose of validating data that was previously protected by that key. These aspects of a key's life cycle are explained in more detail by, e.g., Austin, cited above.
An application conducting a secure transaction does so by using its own digital identity in association with data transmitted by the application to authenticate a transaction. Similarly, an authentication process is used to receive and decode secure data. This authentication is accomplished using a digital certificate to identify a document along with the corresponding application. To prevent misuse of digital certificates, a digital certificate requires validation. Validation of digital certificates is done by certification authorities (CAs).
Trusted nodes in a network function as key distributors and administrators. Certification authorities act as trusted nodes in CA public key architectures. One function of certification is to ensure that a sender's public key does indeed belong to that sender, and not to some other imposter. Since a sender cannot sign its own public key in the same way that it may use its private key to generate a digital signature, a third party needs to independently certify that the sender is who he or she claims to be. The CA serves as this independent third party, and processes public key certificates. The CA provides security services not only to its subscribers, but also to other parties having secure transactions with the subscribers. The other parties may use the CA for services such as non-repudiation of transmissions from the subscribers, and hence the other parties are sometimes referred to as “relying parties.”
A certification authority generates digital certificates, or “certificates,” for use by applications in conducting secure communications. One aspect of digital certificates is that they carry an expiration date, to avoid use of a certificate indefinitely, perhaps to a date exceeding that at which the user is no longer privileged to use the certificate. Furthermore, CA-issued certificates are checked against a certificate revocation list (CRL). The CRL contains certificate information identifying certificates which have not yet expired, but are not to be honored. Certification authorities maintain certificate revocation lists (CRLs) for checking each digital certificate. A CRL is posted and updated about once a day to minimize unauthorized use of revoked certificates.
Entities such as government agencies or businesses conducting electronic business or online transactions may use computer applications designed for handling digital certificates. Such applications include virtual private networking products, e-mail systems, Web browsers and Web servers, Web applications such as changing addresses with government agencies and private sectors, among others. Each of these applications generally includes an application-specific protocol and/or application program interface API for handling digital certificates. An API is defined on Webopedia (www.webopedia.com) as “a set of routines, protocols, and tools for building software applications.”
With the proliferation of nodes and users and agencies associated therewith, more than one CA exist to service the resulting needs. Transactions in the presence of multiple CAs present challenges, especially when transactions are to be conducted between two entities using different CAs. The difficulties that arise are in part due to the fact that the applications need to bear the burden of possessing cross referencing capabilities amongst different CAs in order to confirm the validity of the digital certificates being presented.
Unfortunately, different PKI vendors and CAs provide proprietary APIs, requiring applications based on PKI to take each vendor's specification into account when designing the application. This results in cumbersome and possibly ineffective applications, as an application using PKI would require constant updating to ensure that the most recent version of the application supports all of the standard PKI implementations available from the various PKI vendors.
In addition, the modifications, or changes to existing CAs or the addition of new CAs to a multiple-CA environment, may require costly and unreliable upgrades or modifications to the application environment including both the server and the application sides. Because the information on a digital certificate is public and can be viewed by anyone, an improved user registration system is proposed to enhance a digital certificate holders' capabilities to manage his/her private information associated with his/her identity in the context of PKI systems.
The recently-developed Open Certificate Status Protocol (OCSP) improves on the existing CRL revocation model by permitting effectively real-time revocation list updating, whereas the CRL model updated the revocation lists approximately on a daily basis. This aspect of OCSP improves security and reduces fraud. However, OCSP requires each application support the OCSP request format for each certification authority whose services might be required. Currently, the various software applications supporting PKI formulate their own OCSP requests and then send those to the CAs, requiring continuous updates and version distribution. Furthermore, the individual data fields provided in a digital certification are currently distributed and shared indiscriminately to any CA through which a transaction is being conducted. Users are currently unable to selectively share particular information with different CAs. This could lead to distribution of user information to entities with which the user would not otherwise wish to share information, and in itself presents a privacy issue that digital certification was in part intended to address.